Skip to content

🚨 [security] Update addressable 2.8.8 → 2.9.2 (minor) - #94

Open
depfu[bot] wants to merge 1 commit into
mainfrom
depfu/update/addressable-2.9.2
Open

depfu[bot] wants to merge 1 commit into
mainfrom
depfu/update/addressable-2.9.2

Conversation

@depfu

@depfu depfu Bot commented Nov 13, 2026

Copy link
Copy Markdown
Contributor

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!


Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ addressable (indirect, 2.8.8 → 2.9.2) · Repo · Changelog

Security Advisories 🚨

🚨 Addressable: Regular Expression Denial of Service in templates with certain exploded expressions

Impact

Within the URI template implementation in Addressable, templates using the * (explode) modifier with the /, ., ;, ? or & operators (e.g., {/segments*}, {.ext*}, {;params*}, {?query*}) generate regular expressions vulnerable to catastrophic backtracking. When Template#match or Template#extract is called with a maliciously crafted URI that starts with the operator's leading character, matching takes exponential time, leading to uncontrolled resource consumption and denial of service. An input under 60 bytes is enough to occupy a thread for minutes.

GHSA-h27x-rffw-24p4 (CVE-2026-35611) reported this pattern as fully remediated in 2.9.0. The 2.9.0 fix only made the joiner between exploded members mandatory for templates without an operator, and its regression specs used inputs that never start with the operator's leading character, so the vulnerable part of the expression was never reached. This issue was originally reported in #364 by @ebenoist in 2019 but insufficiently investigated.

Users of the URI parsing capabilities in Addressable but not the URI template matching capabilities are unaffected. Users who only call Template#expand are unaffected.

Affected Versions

This vulnerability affects Addressable >= 2.3.0 (note: 2.3.0 and 2.3.1 were yanked; the earliest installable release is 2.3.2), including 2.9.0. It is fixed in 2.9.1.

The vulnerability is only exploitable on Ruby implementations whose regular expression engine backtracks without memoization: MRI Ruby < 3.2 and JRuby. MRI Ruby 3.2 and later are not affected: their regular expression engine memoizes backtracking, so these patterns still match in linear time. TruffleRuby 40.0 is not affected either. Earlier TruffleRuby versions were not tested.

This has been confirmed on the following runtimes with Addressable 2.9.0:

Runtime Status
MRI Ruby 2.7 Vulnerable
MRI Ruby 3.1 Vulnerable
MRI Ruby 3.2 Not affected
MRI Ruby 3.3 Not affected
MRI Ruby 3.4 Not affected
MRI Ruby 4.0 Not affected
JRuby 9.4 Vulnerable
TruffleRuby 40.0 Not affected

Workarounds

  • Upgrade to MRI Ruby 3.2 or later, if the consuming application does not use JRuby.
  • Avoid matching user-supplied input on unpatched versions of the library against templates that use the * modifier with the /, ., ;, ? or & operators.
  • Apply a short timeout around any call to Template#match or Template#extract that processes user-supplied data.

Credits

Reported independently by @ebenoist, @andrewstellman, and then @halogenandtoast.

For more information

If there are any questions or comments about this advisory:

🚨 Addressable URI normalization resolves some dotted path segments to the wrong path

Summary

Addressable::URI.normalize_path resolves some paths containing .. segments to a different path than RFC 3986 does. When a path climbs above the root before any other .. is resolved, the segments that later .. segments should remove are instead kept: /../../public/x/../../secret normalizes to /public/x/secret instead of /secret. URI#normalize, URI#join, URI#== and URI#=== all use this normalization. An application that checks a normalized Addressable path against an allowlist, but sends the original URI to something that resolves it according to RFC 3986, can be made to allow a request for a path outside the allowlist.

Details

normalize_path in 2.9.0 (lib/addressable/uri.rb) removes dot segments by repeating a set of rewrites until nothing changes. On each pass it finds the first /segment/../ pair with RULE_2B_2C, then replaces every textual copy of that pair in the path with /:

pair = normalized_path.match(RULE_2B_2C)
...
regexp = "/#{Regexp.escape(parent.to_s)}/\\.\\./|"
regexp += "(/#{Regexp.escape(current.to_s)}/\\.\\.$)"
...
mod ||= normalized_path.gsub!(Regexp.new(regexp), SLASH)

When the first pair found is /../../, where the "segment" is itself .., every /../../ in the path is replaced with /. That includes copies later in the path, where each .. should have removed the segment before it. For /../../public/x/../../secret:

  • RFC 3986 §5.2.4 drops the two leading .. segments, which can't go above the root, then removes x and public, giving /secret.
  • 2.9.0 replaces both copies of /../../ with / in one step, giving /public/x/secret.

Paths where an ordinary /segment/../ pair comes first, such as /a/../../b/c/../../d, are resolved correctly.

This was introduced in 2.2.5. Versions 2.0.0 through 2.2.4 and earlier versions resolve these paths correctly. It is fixed in 2.9.1, which replaces the rewrite loop with a single pass that correctly follows RFC 3986 §5.2.4.

Proof of concept

require "addressable/uri"
require "uri"

url = "http://example.com/../../public/x/../../secret"

# Addressable's normalized path, compared with RFC 3986 resolution by Ruby's URI library
puts Addressable::URI.parse(url).normalize.path
puts URI.join("http://example.com/", "../../public/x/../../secret").path

# join and == use the same normalization
puts Addressable::URI.join("http://example.com/", "../../public/x/../../secret").path
puts Addressable::URI.parse(url) == Addressable::URI.parse("http://example.com/public/x/secret")

# An allowlist check on the normalized path passes, but the request reaches /secret
def allowed?(url) = Addressable::URI.parse(url).normalize.path.start_with?("/public/")
puts allowed?(url)

Output with Addressable 2.9.0:

/public/x/secret
/secret
/public/x/secret
true
true

Output with Addressable 2.9.1:

/secret
/secret
/secret
false
false

Impact

This is an interpretation conflict (CWE-436) between Addressable and other RFC 3986 resolvers, which could lead to path traversal past an allowlist (CWE-22). An application is affected when it does both of these:

  • makes an access decision on a path normalized or joined by Addressable, such as "only paths under /public/ may be proxied" or "only these redirect targets are allowed";
  • sends the original, unnormalized URI to a component that resolves dot segments itself, such as an HTTP client, a proxy, a web server or a browser.

An attacker may be able to bypass a check by exploiting behavioral differences between URI parsers. Impact from this is application-dependent. Applications that use Addressable's normalized form for both the check and the request are unaffected, as are applications that reject paths containing .. segments.

As a work-around for unpatched versions, before making access decisions on a path, either reject any containing .. segments, including percent-encoded forms such as %2e%2e, or use the same normalized value for both the check and the request.

🚨 Addressable: Regular Expression Denial of Service in templates with multiple variables

Impact

Within the URI template implementation in Addressable, templates that put several variables in one expression generate regular expressions vulnerable to excessive backtracking:

  1. Expressions with any operator other than + and # (e.g., {/owner,repo,ref}, {.a,b}, {a,b,c}, {;a,b,c}). The values are joined by an optional separator, so a run of characters can be divided among the variables in O(n^k) ways for k variables.
  2. Expressions with the + or # operators and many variables (e.g., {+v1,v2,v3,v4,v5,v6,v7,v8,v9,v10}). A failing match is exponential in the number of variables.
  3. Several single-variable expressions next to each other (e.g., {+a}{+b}{+c} or {a}{b}{c}), which are polynomial in the input length.

When Template#match or Template#extract is called with a maliciously crafted URI, this can result in uncontrolled resource consumption, leading to denial of service. A three-variable path template such as http://example.com/repos{/owner,repo,ref} needs about 2 KB of input to occupy a thread for many seconds.

Users of the URI parsing capabilities in Addressable but not the URI template matching capabilities are unaffected. Users who only call Template#expand are unaffected.

Affected Versions

This vulnerability affects Addressable >= 2.3.0 (note: 2.3.0 and 2.3.1 were yanked; the earliest installable release is 2.3.2), including 2.9.0. It is fixed in 2.9.1.

The vulnerability is exploitable on Ruby implementations whose regular expression engine backtracks without memoization: MRI Ruby < 3.2 and JRuby. The second form, many-variable + and # expressions, is also exploitable on MRI Ruby 3.2, which does not memoize a regular expression that contains possessive quantifiers, and 2.9.0 generates those for these operators. It is also exploitable on TruffleRuby 40.0, whose regular expression engine falls back to backtracking for them. MRI Ruby 3.3 and later are not affected by any form, because they memoize those regular expressions too. TruffleRuby 40.0 is not affected by the other two forms. Earlier TruffleRuby versions were not tested.

This has been confirmed on the following runtimes with Addressable 2.9.0:

Runtime Status
MRI Ruby 2.7 Vulnerable
MRI Ruby 3.1 Vulnerable
MRI Ruby 3.2 Vulnerable
MRI Ruby 3.3 Not affected
MRI Ruby 3.4 Not affected
MRI Ruby 4.0 Not affected
JRuby 9.4 Vulnerable
JRuby 10.1 Vulnerable
TruffleRuby 40.0 Vulnerable

Workarounds

  • Upgrade to MRI Ruby 3.3 or later, if a consuming application does not use JRuby or TruffleRuby.
  • Avoid matching user-supplied input on unpatched versions of the library against templates with several variables in one expression, or with several expressions next to each other.
  • Apply a short timeout around any call to Template#match or Template#extract that processes user-supplied data.

Credits

Reported by Matthew Mongeau (@halogenandtoast), Ruby Central Gem Security.

For more information

If there are any questions or comments about this advisory:

🚨 Addressable display_uri can show misleading hosts with invalid Punycode A-labels

Impact

Addressable::IDNA.to_unicode, in the pure-Ruby IDNA implementation, decodes Punycode labels (labels beginning with xn--) that are not valid A-labels. Those labels are returned in decoded form, when they should be returned unchanged. That includes:

  • labels that decode to only ASCII characters, e.g. xn--google- decodes to google;
  • labels that decode to text that doesn't convert back to the same label (RFC 3490 §4.2), e.g. text that isn't in normalized form.

Addressable::URI#display_uri uses to_unicode, so for https://xn--google-.example.org/ it displays the host google.example.org, while #host, #normalized_host and any connection made from the URI use xn--google-.example.org. An attacker who controls a domain can therefore have a URI displayed as a host they don't control. Applications that compare the result of to_unicode against a list of trusted names can likewise treat two different hosts as the same.

The native IDNA implementation, used when libidn and the idn-ruby gem are installed, is not affected. to_ascii and normalized_host are not affected.

Affected Versions

This vulnerability affects Addressable >= 2.0.0, the first version with the pure-Ruby IDNA implementation, when that implementation is in use. It is fixed in 2.9.1, where such labels are returned unchanged, as with libidn.

Workarounds

  • Install libidn and the idn-ruby gem, so that Addressable uses the native IDNA implementation.
  • Don't make security decisions on display_uri or to_unicode output. Compare hosts using normalized_host.

Credits

Reported by @tonghuaroot.

For more information

If there are any questions or comments about this advisory:

🚨 Addressable: Denial of service in URI path normalization

Impact

Addressable::URI.normalize_path takes time quadratic in the number of nested dot segments in a path (e.g., "/" + "a/" * n + "../" * n, which for n = 3 is /a/a/a/../../../), because it removes one dot segment per pass over the whole path. URI#normalize, URI#normalized_path, URI#==, URI#=== and URI#join all call it. Normalizing, comparing or joining a URI taken from user input can result in uncontrolled resource consumption, leading to denial of service. On 2.9.0, normalizing a 34 KB path takes about 3.5 seconds on MRI Ruby 4.0, and the cost grows with the square of the path length.

This affects every Ruby implementation, including MRI Ruby 3.2 and later. URI.parse by itself is unaffected, as is code that never normalizes, compares, or joins URIs from untrusted sources.

Affected Versions

This vulnerability affects all versions of Addressable prior to 2.9.1. It is fixed in 2.9.1.

Workarounds

  • Limit the length of URIs taken from user input before calling normalize, == or join on them. Web servers often limit request lines to about 8 KB, which keeps the cost to about 150 milliseconds per call on typical hardware, but URIs from other sources (request bodies, headers such as Location, stored data) may not be limited.
  • Reject paths with many dot segments before normalizing them.

Credits

Reported by Matthew Mongeau (@halogenandtoast), Ruby Central Gem Security, who also suggested the single-pass approach used in the fix.

For more information

If there are any questions or comments about this advisory:

🚨 Addressable display_uri can show misleading hosts containing bidi and invisible characters

Impact

Addressable::IDNA.to_unicode decodes Punycode labels (labels beginning with xn--) that contain characters which change how text is displayed without being visible themselves. These include bidirectional controls such as U+202E RIGHT-TO-LEFT OVERRIDE and U+2066–U+2069, zero-width characters, and other invisible format characters. Addressable::URI#display_uri uses to_unicode, so it can display a host whose characters appear reordered or which looks identical to a different host. For example, the host of http://xn--abcmoc-dm0c.com/ is displayed as abc, U+202E, moc.com, and the override makes everything after abc render right to left.

Parsing, host, normalized_host and any connection made from the URI are not affected. Only the displayed form is. Applications that show display_uri to users (link previews, chat and email clients, admin interfaces) can be used to make a malicious domain look like a trusted one.

  • In the pure-Ruby IDNA implementation, all such characters are decoded, including those that IDNA's nameprep profile prohibits.
  • In the native IDNA implementation, used when libidn and the idn-ruby gem are installed, libidn rejects most of them, but not characters added to Unicode after version 3.2, such as U+061C and U+2066–U+2069.

Affected Versions

The pure-Ruby IDNA implementation is affected in Addressable >= 2.0.0. The native IDNA implementation is affected in Addressable >= 2.5.2, when to_unicode began accepting characters unassigned in Unicode 3.2. It is fixed in 2.9.1 for both implementations, where such labels are returned unchanged.

Workarounds

  • Install libidn and the idn-ruby gem, so that Addressable uses the native IDNA implementation. This reduces the affected characters to those added since Unicode 3.2.
  • Check displayed hosts for bidirectional and invisible characters (e.g., /[\p{Cc}\p{Cf}\p{Default_Ignorable_Code_Point}]/) and fall back to normalized_host when one is present.

Credits

Reported by @andrewstellman.

For more information

If there are any questions or comments about this advisory:

🚨 Addressable has a Regular Expression Denial of Service in Addressable templates

Impact

Within the URI template implementation in Addressable, two classes of URI template generate regular expressions vulnerable to catastrophic backtracking:

  1. Templates using the * (explode) modifier with any expansion operator (e.g., {foo*}, {+var*}, {#var*}, {/var*}, {.var*}, {;var*}, {?var*}, {&var*}) generate patterns with nested unbounded quantifiers that are O(2^n) when matched against a maliciously crafted URI.
  2. Templates using multiple variables with the + or # operators (e.g., {+v1,v2,v3}) generate patterns with O(n^k) complexity due to the comma separator being within the matched character class, causing ambiguous backtracking across k variables.

When matched against a maliciously crafted URI, this can result in catastrophic backtracking and uncontrolled resource consumption, leading to denial of service. The first pattern was partially addressed in 2.8.10 for certain operator combinations. Both patterns are fully remediated in 2.9.0.

Users of the URI parsing capabilities in Addressable but not the URI template matching capabilities are unaffected.

Affected Versions

This vulnerability affects Addressable >= 2.3.0 (note: 2.3.0 and 2.3.1 were yanked; the earliest installable release is 2.3.2). It was partially fixed in version 2.8.10 and fully remediated in 2.9.0.

The vulnerability is more exploitable on MRI Ruby < 3.2 and on all versions of JRuby and TruffleRuby. MRI Ruby 3.2 and later ship with Onigmo 6.9, which introduces memoization that prevents catastrophic backtracking for the first class of template. JRuby and TruffleRuby do not implement equivalent memoization and remain vulnerable to all patterns.

This has been confirmed on the following runtimes:

Runtime Status
MRI Ruby 2.6 Vulnerable
MRI Ruby 2.7 Vulnerable
MRI Ruby 3.0 Vulnerable
MRI Ruby 3.1 Vulnerable
MRI Ruby 3.2 Partially vulnerable
MRI Ruby 3.3 Partially vulnerable
MRI Ruby 3.4 Partially vulnerable
MRI Ruby 4.0 Partially vulnerable
JRuby 10.0 Vulnerable
TruffleRuby 21.2 Vulnerable

Workarounds

  • Upgrade to MRI Ruby 3.2 or later, if your application does not use JRuby or TruffleRuby. The Onigmo memoization introduced in MRI Ruby 3.2 prevents catastrophic backtracking from nested unbounded quantifiers (pattern 1 above — templates using the * modifier). It does not reliably mitigate the O(n^k) multi-variable case (pattern 2), so upgrading Ruby alone may not be sufficient if your templates use {+v1,v2,...} or {#v1,v2,...} syntax.

  • Avoid using vulnerable template patterns when matching user-supplied input on unpatched versions of the library:

    • Templates using the * (explode) modifier: {foo*}, {+var*}, {#var*}, {.var*}, {/var*}, {;var*}, {?var*}, {&var*}
    • Templates using multiple variables with the + or # operators: {+v1,v2}, {#v1,v2,v3}, etc.
  • Apply a short timeout around any call to Template#match or Template#extract that processes user-supplied data.

References

Credits

Discovered in collaboration with @jamfish.

For more information

If you have any questions or comments about this advisory:

Release Notes

2.9.2 (from changelog)

  • fixes Addressable::URI returning stale values after a component was changed: e.g. after host=, #site, #normalized_site, #normalized_authority and #normalize could still use the old host, and after scheme=, #normalized_port could keep a port that's the new scheme's default (#613)
  • fixes Addressable::URI#normalized_query reusing the result of an earlier call with different flags: e.g. after normalized_query(:sorted), normalized_query and #normalize gave a sorted query, and after normalized_query, normalized_query(:sorted) gave an unsorted one (#608)
  • fixes Addressable::Template#expand and #partial_expand changing the arrays given as values: e.g. [1, :a] became ["1", "a"]; a frozen array raised FrozenError, and an object that responds to to_ary raised TypeError (#605)
  • fixes Addressable::URI#clone sharing component strings with the original: e.g. appending to the clone's #host also changed the original's host, but not its cached normalized values; #dup already made a separate copy (#617)
  • fixes the pure-Ruby Addressable::IDNA.to_unicode raising ZeroDivisionError on some malformed labels, e.g. xn--rp3=, which also made Addressable::URI#display_uri raise, because the Punycode decoder treated punctuation as digits; such labels are now returned unchanged (#614)
  • speeds up the pure-Ruby Addressable::IDNA.to_unicode, which became up to 25 times slower in 2.9.1 on long labels with many non-ASCII characters; Punycode encoding no longer takes quadratic time (#645)
  • fixes the "character class has duplicated range" warnings that 2.9.1 gave when Addressable::IDNA was loaded with warnings enabled
  • fixes the "instance variable @validation_deferred not initialized" warning that 2.9.1 gave for every new Addressable::URI on Ruby before 3.0 with warnings enabled, and a "shadowing outer local variable" warning from Addressable::Template on Ruby 2.4 and 2.5

2.9.1 (from changelog)

  • fixes denial of service in Addressable::URI.normalize_path, which took quadratic time on paths with many dot segments; URI#normalize, #join, #== and #=== were affected (GHSA-qq38-m9mg-xjj5)
  • fixes Addressable::URI.normalize_path keeping segments that a .. should have removed after a .. above the root, e.g. /../../public/x/../../secret normalized to /public/x/secret instead of /secret (GHSA-8gmh-2hhj-2hv9)
  • fixes Addressable::URI.normalize_path treating a raw line feed as a segment boundary, e.g. joining ..\n/secret onto /public/ gave /\n/secret
  • deprecates Addressable::URI::RULE_2A, RULE_2B_2C, RULE_2D and RULE_PREFIXED_PARENT, which are no longer used; they will be removed in 2.10.0
  • fixes denial of service in Addressable::Template#match and #extract, which still backtracked exponentially in 2.9.0 for exploded /, ., ;, ? and & expressions (e.g. {/path*}) on regex engines without match memoization, such as JRuby, TruffleRuby and MRI before 3.2; match results are unchanged (GHSA-j82w-28jv-3pmj)
  • fixes denial of service in Addressable::Template#match and #extract, which backtracked polynomially or exponentially on the same regex engines for expressions with several variables (e.g. {/owner,repo,ref}, or {+a,b,c} with many variables), for ; expressions, and for adjacent expressions (e.g. {+a}{+b}{+c} or {+a}{b}); match results are unchanged (GHSA-9f42-57jx-vpp3)
  • fixes denial of service in Addressable::Template#match and #extract, which backtracked polynomially for expressions with several exploded variables (e.g. {+a*,b*}), including on MRI 3.2; match results are unchanged (GHSA-4w5q-wg7v-w6gp)
  • fixes Addressable::IDNA.to_unicode in the pure-Ruby backend decoding Punycode labels that aren't valid A-labels: labels that decode to only ASCII characters (e.g. xn--google- decoded to google) and labels that don't convert back to themselves; such a label is now returned unchanged, as with libidn, so Addressable::URI#display_uri no longer shows a host that differs from #normalized_host (GHSA-9crm-g4mf-wc5j)
  • fixes Addressable::IDNA.to_unicode decoding Punycode labels with characters that change how a host displays without being visible themselves, such as bidi overrides and isolates (e.g. U+202E and U+2066), zero width characters and control characters; such a label is now returned unchanged, so Addressable::URI#display_uri no longer shows them. The pure-Ruby backend also no longer decodes labels with other characters that nameprep prohibits, as with libidn (GHSA-539f-xcgw-2gjg)
  • fixes Addressable::URI#route_from and #route_to raising InvalidURIError when the route's first segment contains a colon (e.g. /a:b from /a); the route is now ./a:b (#625)
  • fixes Addressable::IDNA.to_unicode raising in the pure-Ruby backend for Punycode labels that are too long, overflow the decoder, or decode past U+10FFFF; the label is now returned unchanged, as with libidn, so Addressable::URI#display_uri no longer raises for such hosts (#620)
  • fixes Addressable::URI#display_uri raising InvalidURIError for URIs without a host, such as abc or mailto:user@example.com; relative URIs are also no longer displayed with an empty authority (e.g. /path/to was displayed as ///path/to) (#610)
  • fixes Addressable::Template#match and #extract raising Addressable::URI::InvalidURIError for a string that isn't a valid URI; they now return nil, as for any other URI that doesn't match (#621)
  • fixes Addressable::URI#origin= raising InvalidURIError for an origin with an empty port (e.g. http://example.com:), which is the same as no port (#627)

2.9.0 (from changelog)

  • fixes ReDoS vulnerability in Addressable::Template#match (fixes incomplete remediation in 2.8.10)

2.8.10 (from changelog)

  • fixes ReDoS vulnerability in Addressable::Template#match

2.8.9 (from changelog)

  • Reduce gem size by excluding test files (#569)
  • No need for bundler as development dependency (#571, 5fc1d93)
  • idna/pure: stop building the useless COMPOSITION_TABLE (removes the Addressable::IDNA::COMPOSITION_TABLE constant) (#564)

Does any of this look wrong? Please let us know.

↗️ public_suffix (indirect, 7.0.2 → 7.0.5) · Repo · Changelog

Release Notes

7.0.5 (from changelog)

Fixed

  • Fix release crash caused by unconditional rubocop/yard requires in Rakefile.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 32 commits:


Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

@depfu depfu Bot added dependencies Pull requests that update a dependency file depfu 🚨 security Security update or fix labels Nov 13, 2026
@depfu
depfu Bot requested a review from a team November 13, 2026 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file depfu 🚨 security Security update or fix

Development

Successfully merging this pull request may close these issues.

0 participants